max_gc_eligible_epoch returned std::nullopt when the partition
snapshot was empty, causing try_to_collect to report
no_collectible_epoch after listing. L0 objects left over from
previously deleted topics stayed in the bucket forever.

Fall through with snap_revision (controller last applied offset)
as the watermark: this is the zero-iteration case of the existing
join, which already starts at snap_revision and walks it down per
partition.

Safety rests on invariants from the existing algorithm:

- get_partitions ensures that the topic table snapshot is in sync
  with the controller stm (i.e. snap revision)
- L0 objects never have an epoch less than any constinuent topic's
  initial revision ID.

So with an empty topic table at snapshot revision N, any _new_ data
must have an epoch > N. Therefore any L0 objects w/ epoch <= N is
safe to GC.

Includes a ducktape regression test:

- pause GC
- accumulate some L0 objects
- delete the only cloud topic
- resume GC
- assert that orphaned objects drain.

Without the fixt the test times out w/ stuck objects.

Signed-off-by: Oren Leiman <oren.leiman@redpanda.com>
(cherry picked from commit 0eee6a8)